Verifying Optimistic Algorithms Should be Easy

In this paper, we call to bridge the gap between what makes highly-concurrent optimistic algorithms work and current approaches for proving their correctness. The Problem: Verification of Optimistic Concurrent Algorithms Highly-concurrent optimistic algorithms are notoriously hard to verify. In particular, verifying that an optimistic algorithm is linearizable [3] is quite challenging. (See, e.g., [9]). Given a highly-concurrent algorithm, our goal is to find a proof that captures its designer’s intuition as to why the algorithm works. We believe that simple and intuitive proofs can, and should, be obtained by embracing the spirit in which these algorithms are written. In this paper, we show that the intuition behind many optimistic concurrent algorithm can be naturally captured using global invariants,1 à la Lamprot [4], of a particular class: In this class, observations regarding the local state of a thread are completely separated from observations regarding either the local states of other threads or the global state. What Makes Highly-Concurrent Optimistic Algorithms Work? A distinguishing feature of optimistic algorithms is that every thread makes very little assumptions on the environment in which it operates. A thread can rely on a structural invariant of the global state, but it cannot rely on local properties of other threads. A thread operates by checking a local property to establish the validity of an update before it takes place. The local property concerns only its local variables and a small fraction of the global shared memory. When the local property does not hold, indicating that the desired update might lead to a violation of the structural invariant, the thread has the ability to “rollback” its actions, and restart the operation. This approach allows the thread to maintain safety under any environment (possibly by sacrificing progress). A Motivating Example. Fig. 1 shows an optimistic set algorithm. The algorithm is one of the concurrent set algorithms derived in [10]. The code is instrumented with operations that manipulated the set’s abstract value. (The instrumentation, written in italics, is explained in Example 3.) The set is implemented as a sorted singly-linked linked list with designated sentinel Head and Tail nodes. The Head node holds the smallest possible key, denoted −∞, and the Tail node holds the largest possible key, denoted ∞. For simplicity, we illustrate our approach using only two set operations: add and remove, with their standard meaning. (We note that, although omitted, we can handle the contains operation). The key argument to these operations, supplied by the client, must be strictly larger than −∞ and strictly smaller than ∞. Both add and remove use the macro LOCATE to traverse the list and locate an item based on the value of its key. The list traversal performed by LOCATE is optimistic and is done without any form of synchronization. In this paper, we use the term “global invariant” as “global within a the context of the algorithm”, i.e., an invariant concerning the shared resources used to implement the verified data structure, and not as an invariant concerning the whole state.